Content starts here Create a Physical Data Service from a Web Service
This page last changed on Apr 08, 2008.

edocs Home > BEA AquaLogic Data Services Platform 3.0/3.2 Documentation > ALDSP 3.2 New Features Documentation

How To Create a Physical Data Service from a Web Service in ALDSP 3.2

In addition to ALDSP 3.0-level WSDL import capabilities, WSDL files can now be retrieved and utilized through the AquaLogic Common Component Service Consumption Framework (SCF).

This topic is a revision of a similar topic contained in the ALDSP 3.0 Data Services Developer's Guide and includes general information about creating a physical data service from a web service, as well as the AquaLogic Common Navigation Framework.

In ALDSP 3.2 three top-level provider types are identified:

  • WSDL File
  • URI
  • ALSB Proxy

A Web service is a self-contained, platform-independent unit of business logic that is accessible through application adaptors, as well as standards-based Internet protocols such as HTTP or SOAP.

Web services greatly facilitate application-to-application communication. As such they are increasingly central to enterprise data resources. A familiar example of an externalized Web service is a frequent-update weather portlet or stock quotes portlet that can easily be integrated into a Web application.

Similarly, a Web service can be effectively used to track a drop shipment order from a seller to a manufacturer.

Topics

Setting Up the Physical Data Service Creation Wizard

Physical data services are created using a wizard.

Physical Data Service Creation Wizard

Starting the Wizard

To start the physical data service creation wizard:

  1. Right-click on your dataspace project or any folder in your project.
  2. Choose New > Physical Data Service
Creating a New Physical Data Service

Accessing a Web Service

After you select web service as your data source, you are given the option of specifying a WSDL file, URI, or ALSB proxy service.

Selecting Web Service as a Data Source

There are several ways to access a specific web service:

  • From a Web Service Description Language (WSDL) file located in your current ALDSP project or through the AquaLogic Service Consumption Framework (SCF).
  • From a WSDL accessible via a URL.
  • Through an ALSB proxy service.

Locating a WSDL File

You can select a WSDL file in two ways:

  • From your project using the Browse button or
  • By downloading a WSDL to your project through the consumption framework

Browsing to a WSDL

Click Browse to navigate to a WSDL in your current dataspace project.

Downloading a WSDL File via the Service Consumption Framework

To download a WSDL file using the Service Consumption Framework:

  1. Click on Download WSDL...
  2. Select from available Service Resource Options.
  3. Click OK. A SCF message indicating success or failure will appear.
  4. Click Next.
  5. Choose from available operations.
    Downloading a WSDL is similar to downloading a text file. Once it is in your project, you can treat it as local and make changes. Changes made to such a WSDL will not be reflected in the source WSDL. Similarly, any changes to the source WSDL (new operations or changes to the signature) would only be reflected if the WSDL was again downloaded and reimported.
Using the Service Consumption Framework to Access a WSDL

The following table briefly describe available service resources:

Resource Description
Enterprise Repository WSDLs in the associated artifacts folder of the Enterprise Repository
UDDI UDDI resources registered with the UDDI registry.
URI Any valid WSDL accessible via URI (alternatively, use the URI option from the primary dialog)
File System A WSDL retrievable from the local file system
Workspace WSDLs or services in other projects in the Workspace (alternatively, use the Browse button for WSDLs in the current project on the primary dialog).

Selecting the Product Type

For a Workspace service resource, services can be consumed from several types of products. By default, three product types are available:

  • Generic WSDL
  • SAM (Service Assembly Modeler)
  • AquaLogic Data Services Platform

If AquaLogic Service Bus is present, ALSB may also be an option.

Selecting a WSDL from an ALDSP Workspace

If you download a WSDL via SCF through either the Enterprise Repository or Workspace option and you are using the ALDSP or ALSB product type, you can locate and view the originated service of the WSDL using the Navigate to External Service right-click menu option on the WSDL file in the Project Explorer.

Specifying a WSDL URI 

You can select an external WSDL through the URI Web Service Data Source option.

You can test the ability to create a physical data service based on a web service using the following WSDL (available as of this writing):
http://www.whitemesa.net/wsdl/r2/base.wsdl


Importing Metadata from a WSDL

The ALSB Proxy Service Option

To access web services through AquaLogic Service Bus (ALSB) you need to:

  • Provide access and credential information to AquaLogic Service Bus. 
  • Select a proxy service (if there is more than one). 

AquaLogic Service Bus access requires providing the following:

  • Server name
  • Port number
  • User name
  • Password

This information should be available from your AquaLogic Service Bus administrator.

Notes:
  • You must configure the ALSB proxy service to use the sb transport protocol to enable access through ALDSP.
  • The Select Proxy list only shows the WSDL-based AquaLogic Service Bus transport proxies in the ALSB server you are connected to. 

After the required information is provided, the WSDL will become available using the name of the selected proxy service.

Steps in Importing a Web Service

  1. Specify a Web service URL, local WSDL file, or ALSB proxy service.
  2. Click Next. 

Selecting Web Service Operations to Import

From the list of available webservice operations grouped by serviceName and portname, choose the operation that you want to turn into data service operation.

Selecting Web Service Operations

During the import process you will be choosing the operations you want to import, setting names and other characteristics. These choices will determine whether a Library or Entity data service will be created. Thus a familiarity with the operations of your Web service is needed.

Adding Operations to an Existing Data Service

You can add operations to an existing physical data service based a web service by adding an external function from the same WSDL.

Add an External Function to an Existing Physical Data Service
Adding an External Operation to a Data Service 

Steps Involved in Selecting Web Service Operations

  1. Select the operations you want to turn into data services or library data service functions.
  2. Click Next. 

Setting Characteristics of Imported Web Service Operations

The following table describes available options for each operation you have selected to import.

Options Available for Imported Web Service Operations
Characteristic
Options
Comment
Operation
adjust as needed
You can change the nominated name to any legal XML name using the built-in line editor.
Public
Boolean
By default Web service-derived operations are protected. A checkbox allows you to mark any function or procedure as public. (Once in a data service, operations can be marked private as needed.)
Kind
  • Read
  • Create
  • Update
  • Delete 
  • Library function
  • Library procedure
Operations determined to return void are automatically marked as library procedures.
You can change the nominated function type. The wizard attempts to correctly set the function type being imported.

Operations marked as create, update, or delete functions will be packaged in an Entity data service. Otherwise, the resulting data service will be of type Library.
Primary
Boolean
Not applicable for web service operations.
Root Element
Root element of the operation
For complex data types the topmost element is listed. In case of RPC-style web services the top-most generated element is listed.
Target Namespace imported value This represents the target namespace of the generated data service. 
Setting Characteristics of Imported Web Service Operations 

Setting the Data Service Name

You can change the name of your data service to any legal name that does not conflict with another name in the current data space.

In addition, if there already is a data service in your project based on the same WSDL an option to add the new operation to the existing data service appears. 

When importing a web service operation that itself has one or more dependent (or referenced) schemas, the wizard creates second-level schemas according to internal naming conventions. If several operations reference the same secondary schemas, the generated name for the secondary schema may change if you re-import or synchronize with the Web service.

Generally Available Test WSDLs

As of this writing the following sample URIs can be used for experimentation with importing WSDLs as data services:

Implementation Notes

This section contains implementation notes.

Special Considerations when Creating a Data Service Based on a RPC-Style Web Service

In case of RPC-style web services, results are return as qualified or unqualified based on the setting of the schema attribute:

elementFormDefault

In the general case of web services, elementFormDefault can be overridden by setting the form attribute for any child element. However, such individual settings are ignored for RPC-style web services since only the global setting (qualified or unqualified) is taken into account.

For example:

<s:schema elementFormDefault="qualified"
   targetNamespace="http://temp.openuri.org/SampleApp/CustomerOrder.xsd"
   xmlns:s0="http://temp.openuri.org/SampleApp/CustomerOrder.xsd"
   xmlns:s="http://www.w3.org/2001/XMLSchema">
  <s:complexType name="ORDER">
    <s:sequence>
      <s:element minOccurs="0" maxOccurs="1" form="unqualified" name="ORDER_ID" type="s:string"/>
      <s:element minOccurs="0" maxOccurs="1" form="unqualified" name="CUSTOMER_ID" type="s:string"/>
    </s:sequence>
  </s:complexType>
</s:schema>

In the above code the global element is qualified but a child element (ORDER_ID) is unqualified.

In the standard case, the special setting of "unqualified" for ORDER_ID will be honored. In the case of RPC-style web services, however, the runtime will generate "qualified" attributes for all the elements, including ORDER_ID.

RPC-style web services such as those generated by ADO.NET may contain child elements with "form" attributes which do not match the schema's elementFormDefault declaration. In order for such web services to be turned into executable data service operations, make sure that all form element attributes and the elementFormDefault attribute are in agreement (either "qualified" or "unqualified").

Multi-dimensional Arrays in RPC Mode

Multi-dimensional arrays in RPC mode are not supported.

See Also

How To Create SOAP Handlers for Imported WSDLs

Document generated by Confluence on Apr 28, 2008 16:19